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IN THE UNITED STATES PATENT AND TRADEMARK OFFICE 
BEFORE THE BOARD OF PATENT APPEALS AND INTERFERENCES 

In Re Application of: 
Salmi et al 

Serial No.: 10/099,902 Examiner: Asghar H. Bilgrami 

Filed: March 13, 2002 Group Art Unit: 2143 

For: REALIZATION OF PRESENCE MANAGEMENT 

Mail Stop Appeal Brief-Patents 
Commissioner for Patents 
P.O. Box 1450 
Alexandria, VA 22313-1450 

BRIEF OF APPELLANT (37 CFR § 41.37 ) 

Sir: 

This brief is in furtherance of the Notice of Appeal filed in this case on January 3, 2006. 
This is an appeal from the Final Office Action dated September 29, 2005 rejecting claims 1-62. 



I. REAL PARTY IN INTEREST (37 CFR $ 41.37(c)(1) (i)) 

The real party in interest is Nokia Corporation, a corporation duly organized and existing 
under the laws of Finland. 

II. RELATED APPEALS AND INTERFERENCES (37 CFR § 41. 37(c)(2)(h)) 
There are no related appeals or interferences. 

III. STATUS OF CLAIMS (37 CFR $ 41.37(c)(l)(iii)) 
Claims 1-62 are pending, and all claims stand rejected. 
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IV. STATUS OF AMENDMENTS (37 CFR § 41.37(c)n¥ivV) 

The last response submitted by Applicants was mailed November 28, 2005, and was 
entered. 

V. SUMMARY OF CLAIMED SUBJECT MATTER (37 CFR § 41.37(c)(nfv)) 

The present invention relates to a data structure defining a presence protocol, a device, a 
server, a system and method to provide management of presence information as a standalone 
service, and as part of the instant messaging service of a communication system. See Abstract. 

Independent claim 1 recites a data structure including a plurality of primitives. See page 
19, lines 25-27. Each primitive is at least temporarily stored in a computer readable medium of a 
client and a computer readable medium at a server during transfer of the primitives over a 
network between the client and server. The data structure of claim 1 includes a get presence 
primitive 32 provided from a client of a requesting user to a server, in order to request presence 
information of a requested user. See page 27, lines 21-22; FIG. 3 A. The get presence primitive 
32 has various information elements including a requesting user identifier, a requested user 
identifier, and a list of presence values requested. See page 29, lines 3-7; Table 3. The data 
structure of claim 1 also includes a presence primitive 33 provided from the server to the 
requesting user client to provide the presence information of a requested user. See page 27, lines 
22-23; FIG. 3 A. The presence primitive 33 has various information elements including the 
requested user identifier and a list of presence values supplied. See page 29, lines 9-12. 

Independent claim 22 recites a presence information service management method for use 
by a server. The method of claim 22 includes a step of the server receiving presence 
authorization messages initiated by users in order to pre-authorize access to selected presence 
information of the users. See page 28, lines 12-20; FIG. 4D. The method of claim 22 also 
includes a step of the server receiving presence information update messages initiated by 
updating users. See page 28, line 27 — page 29, line 3. The method of claim 22 further includes 
a step of the server receiving presence information request messages from presence service 
requesting users including users requesting presence information to which a response is required 
and including subscribing users initially subscribing to presence information to which on-going 
responses including requested presence information are required. See page 27, lines 21-22; page 
31, lines 28-30. The method of claim 22 also includes a step of the server determining if access 
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to the requested presence information has been pre-authorized and, if not, requesting 
authorization from a user whose presence information has been requested. See page 29, lines 7- 
12. Furthermore, claim 22 includes a step of the server providing the requested presence 
information to the users who have requested the presence information, and providing requested 
presence information on an on-going basis to the subscribing users particularly after receiving 
the presence information update messages from said updating users. See page 27, lines 22-23; 
page 31, lines 28-30. 

Independent claim 42 recites a server for carrying out a presence information service 
management method for clients. The server has a means 625, 133p for receiving presence 
authorization messages 37, 38, 64, 84 initiated by users to authorize access to selected presence 
information of the users. See page 36, lines 11-16; FIG. 4D. Means 133p comprises a signaling 
mechanism that sends signals to a mechanism that determines if acquisition of the presence 
information by the requesting client has been authorized. The server of claim 42 also has a 
means 425 for receiving presence information update messages 31, 35, 86 initiated by updating 
users. See FIG. 4D. The server of claim 42 further comprises a means 46s, 133i for receiving 
presence information request messages from presence server requesting users including users 
requesting presence information to which a response is required and including subscribing users 
initially subscribing to presence information to which on-going responses including requested 
presence information are required. See page 30, lines 9-14; FIG. 3C; page 36, lines 1-6; FIG. 
4D. Means 133i comprising a mechanism that retrieves requested presence information. 
Furthermore, claim 42 includes a means 133f for determining if access to the requested presence 
information has been authorized and, if not, requesting authorization 133n from a user whose 
presence information has been requested. See page 36, lines 7-21 ; FIG. 4D. Claim 42 also 
includes a means 50s, 133k for providing the requested presence information to which a response 
is expected to the requesting users and for providing requested presence information on an on- 
going basis to the subscribing users subscribing to presence information update messages from 
the updating users. See page 30, lines 9-14; FIG. 3C; page 36, lines 4-6; FIG. 4D. 
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VI. 



GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL (37 CFR 



§ 4L37(cVn(vm 



Claims 1-62 are rejected under 35 U.S.C. § 102(e) as being anticipated by Gudjonsson et 
al. (U.S. Patent No. 6,564,261). 

VII. ARGUMENT (37 CFR § 41.37(c)m(Vii) 
Independent claim 1 

The Examiner interpreted the limitations of claim 1 too broadly. Claim 1 does not cover 
a subscribed presence model as stated by the Examiner, because a "get presence primitive" does 
not include a subscription request. During patent prosecution an examiner must give claims their 
broadest reasonable interpretation consistent with the specification. MPEP §2111. This 
requirement ensures that once a claim issues it is not interpreted more broadly than justified. 
However, the examiner is limited in how broad an interpretation can be given to a claim. The 
interpretation of a claim must be "reasonable." In re Morris, 44 USPQ2d 1023, 1028-29 (Fed. 
Cir. 1997) (question is whether the PTO's interpretation of the disputed claim language is 
"reasonable"). In addition, the interpretation must be "consistent with the specification." In re 
Cortright, 49 USPQ2d 1464, 1467 (Fed. Cir. 1999). 

In the first Office Action of May 6, 2005 the Examiner interpreted "get presence 
primitive" to mean a "subscription request." Then in the final Office Action of September 29, 
2005 the Examiner attempted to support his position by stating that "get presence primitive" 
means all kind of status information, and that all kinds of status information includes 
subscription information. Claim 1 only covers the unsubscribed presence model discussed on 
page 27 of the specification. Interpreting "get presence primitive" to mean a "subscription 
request" expands the scope of claim 1 to include the subscribed presence model, and is 
unreasonable and inconsistent with the specification. The Examiner's interpretation is too broad 
and covers elements not included in the scope of claim 1 . 

The Examiner asserted that all kinds of status information includes subscription 
information. This interpretation is unreasonable because the Examiner ignored interpretive 
guidance afforded by the applicant's specification. In re Morris, 44 USPQ2d at 1027. Presence 
information is the same as status information. However, it is clear that "status information" does 
not include a subscription request. The specification of the current application makes it clear that 
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presence is information about a user, for example "emotional status such as mood and 
willingness for communication." See page 1, lines 22-26. While it is true that presence and 
status refer to the same concept, these refer to attributes that are personal to a user. See page 4, 
lines 3-7 (presence information is classifiable as user availability, or user personal status). Status 
is different than a subscription request because it is personal to a user. See page 22, lines 17-19. 
A subscription request is a command generated by a user in order to subscribe to another user's 
status information. For example, Figure 4D demonstrates that the GetPresence 32 primitive is a 
separate message from the SubsPresence 80 primitive. The guidance provided by the 
specification makes it clear that status information does not include subscription information. 
Therefore, a get presence primitive as used in claim 1 does not include a subscription request, 
because claim 1 only recites the unsubscribed presence model. 

In addition, the PTO's interpretation of a claim term is inconsistent if it is so broad that is 
conflicts with the meaning given to identical terms in other patents from analogous arts. In re 
Cortright, 49 USPQ2d at 1467. The Examiner cites Gudjonsson as prior art, but Gudjonsson 
does not define presence information to include a subscription request. Gudjonsson refers to 
presence data of a user as arbitrary sets of data related to the identity of each user. See column 8, 
lines 53-56. Gudjonsson indicates that presence data of a user is different than a subscription 
request, and the Examiner has interpreted "get presence primitive" in a way that is inconsistent 
with the specification and the prior art. Therefore, the interpretation of get presence primitive by 
the Examiner is incorrect, and claim 1 must be interpreted to only include an unsubscribed 
presence model. 

Gudjonsson only teaches obtaining presence information of a user when another use has 
subscribed to that user's presence information. In contrast, present claim 1 recites a situation in 
which an unsubscribed user is able to retrieve presence information of another user. The present 
invention makes this possible by providing separate presence service parts 12a, 12b of the EM 
services capabilities layer 12. See FIG. IB. 

The differences between the unsubscribed presence and subscribed presence models will 
now be summarized. Compare the unsubscribed presence model shown in Figure 3A, and the 
subscribed presence model shown in Figure 4A. Notice that the "get presence" primitive on the 
line 32 requires the presence server 27 to request presence authorization by sending a signal on 
the line 36 to another IM client. Only after an authorization signal is received on the line 37 is 
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the presence sent on the line 33 from the presence server 27 to the IM client that originated the 
"get presence" request on the line 32. The "get presence" primitive means that the IM client on 
the left hand side of Figure 3A is not already subscribed to the presence information of the IM 
client on the right hand side. The presence server 27 has to then, right then and there, go get the 
presence information before it can send the presence information to the requesting IM client. 
This interpretation is the only reasonable interpretation that is consistent with the specification 
and prior art. In the unsubscribed presence model, a user can obtain presence information for 
another t user separately from messaging services by issuing a query to the presence server. See 
page 27, lines 15-16; FIG. 3 A. A user issues a get presence message 32 in order to request the 
presence information of some other user, and then the other user's presence information is 
delivered back to the requesting user. See page 27, lines 21-23. Gudjonsson does not teach or 
suggest obtaining presence information of a user without first being subscribed to that user's 
presence information. 

The "subscribed presence" model is shown as an additional part of the claimed data 
structure. See page 31, line 20; Fig. 4A. This additional feature is claimed in dependent claim 4. 
In the subscribed presence model, a subscribed presence signal on a line 80 is sent to the 
presence server where the presence server recognizes the subscribed presence primitive as 
requesting a subscription to presence information, in the sense used by the Examiner. The 
presence server again requests authorization but on an ongoing basis so that once the presence 
server receives the authorization, it will send the presence information not only immediately as 
on the line 88 but also after updates such as the updates shown on the line 86 followed by 
sending the updated information on the line 90 without any need for a separate request from the 
IM client on the left. 

The Examiner cites column 11, lines 43-64 of Gudjonsson as teaching the elements 
recited in claim 1 . However, this portion fails to teach or suggest an unsubscribed model for 
obtaining a user's presence information. Gudjonsson teaches the use of a "contact list" that is 
maintained by the user and includes other individuals that the user knows and has contact with. 
See column 11, lines 46-49. The contact list is the equivalent of the subscribed presence model 
of the present invention. The owner of the contact list must select individuals to be on the 
contact list, and thereby "subscribe" to their presence information. The user can subscribe to an 
individual's presence information by entering new contacts, but the user must first know the 
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contacts system/network identity, or search a directory based on various criteria. See column 11, 
lines 59-63. Furthermore, the statement, "the list may show the online status of these other 
users," makes it apparent that the online status (i.e. presence information) of a user can only be 
obtained after the contact list owner adds the user to his or her contact list. See column 11, lines 
51-52. This fact becomes even clearer when considered in light of column 12, lines 55-65. This 
section describes a variety of functions available to a contact list user, but only after the user has 
selected a user from the contact list. For instance, the contact list owner (selecting user 7) can 
display information about a given contact, and the contact is defined as a user selected from the 
contact list. See column 12, lines 57-58. 

The Examiner also cites column 26, lines 40-58 of Gudjonsson as disclosing the 
limitations of present claim 1 . However, this section also fails to disclose or suggest an 
unsubscribed model for obtaining presence information as recited in claim 1. A user's online 
status (i.e. presence information) is subscribed from the responsible user server (US) 19 by 
connection servers (CS) 21 that are watching the user as someone 's contact. See column 26, 
lines 42-45. Gudjonsson requires that a user be someone's contact (i.e. their information has 
been subscribed to) before a CS will watch the user and make their information available to other 
users. Therefore, Gudjonsson only discloses the subscribed presence model and not the 
unsubscribed presence model as recited in claim 1 . 

The fact that Gudjonsson fails to disclose or suggest an unsubscribed presence model is 
also evident from column 8, lines 53-65. This section describes the basic set of features that the 
invention disclosed by Gudjonsson provides. Feature 5 allows each user 7 the ability to monitor 
the status/presence of a given set of other users. See column 8, lines 60-62. The given set of 
other users is the group of users that a user 7 has subscribed to, in contrast to an unsubscribed 
model as recited in claim 1 in which a user can get presence information on any user. 
Furthermore, feature 6 provides each user 7 the ability to look for other user's identities using 
queries by name or other useful criteria. While a user 7 can find the identity of a particular user, 
the user 7 cannot get presence information until that user finds another user and subscribes to 
that user's presence information. Therefore, Gudjonsson fails to disclose or suggest the 
unsubscribed presence model recited in claim 1 . 

A claim is only anticipated if each and every element as set forth in the claim is found, 
either expressly or inherently described in a single prior art reference. In re Robertson, 49 
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USPQ2d 1949, 1950 (Fed. Cir. 1999); MPEP § 2131. Therefore, claim 1 is not anticipated 
because every element of claim 1 is not described by Gudjonsson. 
Dependent Claim 2 

Claim 2 recites an option in which an authorization sequence may occur between the "get 
presence" message on the line 32 and the presence delivery on the line 33. See page 28, lines 
12-22. Claim 2 recites an authorization sequence wherein after the unsubscribed request for 
presence information on the line 32 an authorization request 36 is sent to the user to authorize the 
presence information, as shown by an authorization message at line 37. Gudjonsson does not 
disclose or suggest an authorization sequence prior to the retrieval of a user's presence 
information. Therefore, for this reason and for the same reasons as discussed in relation to 
independent claim 1 because dependent claim 2 depends directly from claim 1, and contains all 
the limitations therein, claim 2 is not anticipated by Gudjonsson. 
Dependent Claims 3-21 and 62 

Dependent claims 3-21 and 62 depend directly or indirectly from claim 1, contain all the 
limitations therein, and are not anticipated by Gudjonsson for the same reasons as discussed in 
relation to independent claim 1 . 
Independent Claim 22 

Claim 22 recites a method for presence information service management, and is rejected 
as anticipated by Gudjonsson. However, Gudjonsson does not disclose all the limitations of 
claim 22. 

The method of claim 22 includes a step of a server receiving presence authorization 
messages from users that are initiated by the users to preauthorize access to selected presence 
information. Gudjonsson does not disclose the receipt by a server of user presence authorization 
messages. While Gudjonsson does disclose users being able to centrally define and modify data 
points linked to them, this is not the equivalent of a presence authorization message to 
preauthorize access to selected presence information. Gudjonsson only discloses modification of 
user "presence" information, and does not disclose that this modification includes pre- 
authorization release of their presence information when requested. In contrast, claim 22 recites 
that users can control access of other users to their presence information by sending the server a 
presence preauthorization message. 
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In addition, claim 22 recites both the unsubscribed presence and subscribed presence 
models within the same independent claim. The third step of claim 22 recites that the server 
receives presence information request messages from users that include users requesting 
presence information to which a response is required and subscribers initially subscribing to 
presence information to which on-going responses including requested presence information are 
required. Gudjonsson does not disclose an unsubscribed presence model combined with a 
subscribed presence model, as is presently claimed in claim 22. 

Column 17, lines 19-37 of Gudjonsson refers to subscribed contact status services only, 
not unsubscribed. The definitions in column 6, lines 44-55 do not disclose a user request of 
presence information to which a response is required as distinguished from subscribing users 
initially subscribing to presence information to which on-going responses including requested 
presence information is required. Although the word "request" is defined in general it does not 
give any further details of the nature of the request. The passages following in column 11, 
beginning at line 31 and ending at line 64 again relate to subscribed presence, not unsubscribed 
presence combined with subscribed presence, as in claim 22. Figure 17 of Gudjonsson does not 
show the kind of data structure needed to carry out the unsubscribed presence model claimed in 
claim 22 wherein both (a) users requesting presence information to which a response is required, 
and (b) subscribing users initially subscribing to presence information to which on-going 
responses including requested presence information are required. 

Furthermore, claim 22 recites a step of a server determining if a user has authorized 
access to presence information, and if not, an authorization is requested from the user whose 
information was requested. Gudjonsson does not disclose determining if a user has authorized 
access to his or her presence information. Column 1 1 , lines 3 1-64 of Gudjonsson merely 
describes a user logging onto an application, which includes functions such as "a contact list." 
Gudjonsson only discusses whether a user is currently logged onto the system or, and whether or 
not the user is immediately reachable. There is no mention of a server determining whether a 
user has authorized access to his or her presence information. Providing an indication of whether 
a user is "immediately reachable" is not the same as determining whether release of a user's 
presence information has been authorized. 

The Examiner cited to column 26, lines 40-64 of Gudjonsson as disclosing this step of 
claim 22, however this portion likewise fails to disclose the limitations of claim 22. Specifically 
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lines 48-50 state, "When a [user server] US 19 gets a contact list request on a user that hasn't 
been loaded it loads the user data from the database." This disclosure is entirely different than 
what is recited in claim 22. In claim 22, when a user's presence information is requested, the 
server determines whether the user has authorized access, and if not, authorization is requested 
before information is released. While column 26, lines 62-64 do state that the server filters out 
blinded users when sending status updates, which arguably can be interpreted as teaching this 
step of claim 22, it still fails to disclose the limitations recited in this step of claim 22. First, 
there is no request for authorization from a user whose presence information has been requested 
when access has not been pre-authorized; instead blinded users are filtered out automatically. 
Second, each user's blinded list cannot be active at the same time as their seeing list. See 
column 27, lines 1-4. In contrast, claim 22 is not limited in this respect because access is 
determined on a case by case basis when a user's presence information is requested. 

A claim is only anticipated if each and every element as set forth in the claim is found, 
either expressly or inherently described in a single prior art reference. In re Robertson, 49 
USPQ2d at 1950; MPEP § 2131. Therefore, claim 22 is not anticipated because Gudjonsson 
does not describe every element of claim 22. 
Dependent Claims 23-41 

Dependent claims 23-41 depend directly or indirectly from claim 22, contain all the 
limitations therein, and are not anticipated by Gudjonsson for the reasons discussed above in 
relation to independent claim 22. 
Independent Claim 42 

Independent claim 42 recites a server for carrying out a presence information service 
management method for clients, and includes similar limitations as those recited in independent 
claim 22. For the same reasons discussed in relation to independent claim 22, claim 42 is not 
anticipated by Gudjonsson. 
Dependent Claims 43-61 

Dependent claims 43-61 depend directly or indirectly from claim 42, contain all the 
limitations therein, and are not anticipated by Gudjonsson for the reasons discussed above in 
relation to independent claim 42. 
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Conclusion 

In view of the above arguments, it is respectfully submitted that the reasoning 
rejection of these claims is in error, and should be reversed. 
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VIII. CLAIMS APPENDIX (31 CFR § 41.37(c)(l)(viii)) 

1 . (Original) A data structure including a plurality of primitives, each primitive for at least 
temporary storage in a computer-readable medium at a client and in a computer readable medium 
at a server during transfer of said primitives over a network between the client and the server, 
characterized in that 

the data structure includes a get presence primitive (32) provided from a client of a 
requesting user to a server to request presence information of a requested user, that the get 
presence primitive has various information elements including a requesting user identifier, a 
requested user identifier, and a list of presence values requested, that 

the data structure includes a presence primitive (33) provided from the server to the 
requesting user client to provide the presence information, and that the presence primitive has 
various information elements including the requested user identifier and a list of presence values 
supplied. 

2. (Original) The data structure of claim 1, characterized in that 

the data structure includes a request presence authorization primitive (36) provided from 
the server to a requested user client to request authorization to provide presence information of 
the requested user to the requesting user, that the request presence authorization primitive 
includes various information elements including the requesting user identifier, that 

the data structure includes an authorize presence primitive (37) provided from the 
requested user client to the server to authorize transfer of the presence information of the 
requested user to the requesting user, and that the authorize presence primitive includes various 
information elements including the requesting user identifier. 

3. (Original) The data structure of claim 1, characterized in that 

the data structure includes an update presence primitive (31) provided from a client of an 
updating user to the server to provide updated presence information of the updating user, and that 
the update presence primitive includes various information elements including an updating user 
identifier and a list of presence values to be updated. 

4. (Original) The data structure of claim 1, characterized in that 
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the data structure includes a subscribe presence primitive (80) provided from a client of a 
subscribing user to the server to request a subscription to presence information, and that 

the subscribe presence primitive includes various information elements including a 
subscribing user identifier. 

5. (Original) The data structure of claim 1, characterized in that 

the data structure includes an authorize presence primitive (37, 84) autonomously 
provided from an initiating client to the server to authorize transfer of presence information of a 
user of the initiating client to an authorized user, and that the autonomously provided authorize 
presence primitive includes various information elements including an identifier for identifying 
the user of the initiating client. 

6. (Original) The data structure of claim 1, characterized in that 

said presence information is classifiable in any one or more of the following: client 
reachability, user availability, user personal status, user or client location, and client capabilities. 

7. (Original) The data structure of claim 1, characterized in that 

the data structure includes a message primitive (140, 142) provided from a message 
sending client to the server and from the server to a message receiving client, and that 

the message primitive has various information elements including a sending client 
identifier, a sending user identifier, and a message content type identifier. 

8. (Original) The data structure of claim 7, characterized in that 

the data structure includes a delivery primitive (144, 146) provided from the server to the 
message sending client, and that 

the delivery primitive has various information elements including status of message 
delivery. 

9. (Original) The structure of claim 7, characterized in that 

the data structure includes a join group primitive (190) provided from a joining client to 
the server, and that 
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the join group primitive includes information elements including a group identifier. 



10. (Original) The data structure of claim 7, characterized in that 

the data structure includes a leave group primitive (192) provided from a leaving client to 
the server, and that 

the leave group primitive includes various information elements including an 
identification of a session. 

1 1 . (Original) The data structure of claim 7, characterized in that 

the data structure includes a group left primitive (194) provided from the server to a 
client, and that 

the group left primitive includes various information elements including an identifier of a 
reason for a leaving. 

12. (Original) The data structure of claim 7, characterized in that 

the data structure includes a create group primitive (400) provided from a group creating 
client to the server, and that 

the create group primitive includes various information elements including a message 
identifier, a transaction identifier and an identifier of properties of the group. 

13. (Original) The data structure of claim 9, characterized in that the join group primitive 
includes information elements including a message identifier, a transaction identifier and said 
group identifier. 

14. (Original) The data structure of claim 7, characterized in that 

the data structure includes a delete group primitive (412) provided from a deleting client 
to the server, and that 

the delete group primitive includes various information elements including a message 
identifier, a transaction identifier and a group identifier. 

15. (Original) The data structure of claim 7, characterized in that 
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the data structure includes a modify group primitive (408) provided from a modifying 
client to the server, and that 

the modify group primitive includes various information elements including a message 
identifier, a transaction identifier and a group identification. 

16. (Original) The data structure of claim 7, characterized in that 

the data structure includes a get group info primitive (404) provided from a client 
requesting group information to the server, and that 

the get group info primitive includes various information elements including a message 
identifier, a transaction identifier and a group identifier. 

17. (Original) The data structure of claim 1, characterized by said presence values associated 
with corresponding presence attributes classified and typed according to a standard. 

18. (Original) A device having means for at least temporarily storing a data structure for 
transmission or reception, characterized in that said data structure is according to claim 1 . 

19. (Original) A system having at least one server able to communicate with a plurality of 
devices, wherein a communication protocol is used between the at least one server and the 
plurality of devices with a data structure according to claim 1. 

20. (Original) The system of claim 19, characterized by said presence values having 
associated space and time information useable by said at least one server to modify said presence 
values or related presence values. 

21. (Original) The system of claim 20, characterized by said presence values having a 
validity attribute associated to said space and time information. 

22. (Original) Presence information service management method for use by a server, 
characterized by 
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a step of said server receiving (37, 38, 64; 84) presence authorization messages from 
users wherein said presence authorization messages are initiated by said users to pre-authorize 
access to selected presence information of said users, by 

a step of said server receiving (31, 35; 86) presence information update messages from 
updating users wherein said update messages are initiated by said updating users, by 

a step of said server receiving (32; 80) presence information request messages from 
presence service requesting users including users requesting presence information to which a 
response is required and including subscribing users initially subscribing to presence information 
to which on-going responses including requested presence information are required, by 

a step of said server determining (133f) if access to said requested presence information 
has been pre-authorized and, if not, requesting authorization (36, 54; 82) from a requested user 
whose presence information has been requested, and if authorized or pre-authorized, by 

a step of said server providing (33) said requested presence information to which a 
response is expected to said requesting users requesting presence information to which a 
response is expected and providing (88, 90) requested presence information on an on-going basis 
to said subscribing users subscribing to presence information to which on-going responses are 
required, particularly after receiving said presence information update messages from said 
updating users. 

23. (Original) The presence information service management method of claim 22, 
characterized in that each of said presence information request messages comprises a primitive 
having various mandatory information elements including a message identifier, a transaction 
identifier, and an identification of a requested user. 

24. (Original) The presence information service management method of claim 23, 
characterized in that said primitive has at least one optional information element comprising a 
list of presence values requested. 

25. (Original) The presence information service management method of claim 22, 
characterized in that said step of requesting authorization from a requested user is carried out by 
means of an authorization message comprising a primitive having various mandatory 
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information elements including a message identifier, an authorization request transaction 
identifier, a requesting user identifier and a list of presence values. 

26. (Original) The presence information service management method of claim 22, 
characterized in that presence information is authorized by means of said authorization messages 
from authorizing users each comprising an authorization primitive having various mandatory 
information elements including a message identifier, an authorization request transaction 
identifier, a requesting user identifier, and a list of presence values. 

27. (Original) The presence information service management method of claim 26, 
characterized in that said primitive has at least one optional information element comprising a 
group identifier if authorization is related to a group. 

28. (Original) The presence information service management method of claim 22, 
characterized in that a buddy list user maintains one or more buddy lists on a server for sending 
messages to one or more recipient users separately or to a whole buddy list, wherein the recipient 
users are not necessarily aware of the buddy list and cannot refer to the buddy list with any 
replies they make, and said buddy list user maintaining one or more buddy lists on said server is 
able to access buddy list presence information. 

29. (Original) The presence information service management method of claim 22, further 
characterized by 

a step of said server receiving (190) join group primitives from member users joining a 
private user group, by 

a step of said server providing (186) presence primitives indicative of presence 
information of member users of said private user group to each member user upon joining said 
private user group but not after departing, and by 

a step of said server providing (194) group left primitives indicative of departed member 
users to remaining private user group member users upon receipt (192) of leave group primitives 
indicative of said departing member users. 
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30. (Original) The presence information service management method of claim 29, 
characterized in that member users are joined by said step of joining only if said join group 
message is preceded by a step of providing an invitation to join primitive to said joining member 
user. 

31 . (Original) The presence information service management method of claim 22, further 
characterized by 

a step of said server receiving (400) a create group primitive from a member user creating 
a user group, said create group primitive having information elements indicative of identification 
of a client used by the user creating the user group, identification of the member user creating the 
user group, and a list of member users of the user group, by 

a step of said server reporting (402) to the member users with a group information 
primitive indicative of establishment of the user group and selected group information, and by 

a step of said server permitting member users of the user group to interchange message 
primitives. 

32. (Original) The method of claim 31, further characterized by 

a step of said server receiving (404) a request for group information from a requesting 
member user, and by 

a step of said server reporting (406) to the requesting member user with a group 
information primitive indicative of selected group information. 

33. (Original) The method of claim 3 1 , further characterized by 

a step of said server receiving (408) a request to modify said user group from a requesting 
member user, and by 

a step of said server reporting (410) to the requesting member user with a group 
information primitive indicative of selected group information. 

34. (Original) The method of claim 31, further characterized by 

a step of said server receiving (412) a request to delete said user group from a requesting 
member user, and by 
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a step of said server reporting to the member users with a status primitive indicative of 
disestablishment of said user group. 

35. (Original) The presence information service management method of claim 22, further 
characterized by 

a step of said server receiving (550) a store content primitive from a storing user and 
storing any content conveyed in a content information element of said content primitive along 
with or according to information elements identifying said store content primitive, a store 
transaction, a storing user, a storing client used by said storing user, a group, properties of said 
content, and a header of said content, by 

a step of said server providing (552) a content information primitive to member users in 
said group having information elements identifying said content information primitive, said store 
transaction, and said header, by 

a step of said server receiving (562) a get content information primitive from a retrieving 
user in said group having information elements identifying said get content primitive, a retrieval 
transaction, the retrieving user, a retrieving client used by said retrieving user, and said group, 
and by 

a step of said server providing (565) a receive content primitive to said retrieving user 
having information elements identifying said receive content primitive, said retrieval transaction, 
said group, said content, said header of said content, and having an information element 
containing shared content for storing among said member users. 

36. (Original) The method of claim 29, further comprising the steps of 

a step of said server receiving (564) a delete content primitive from a deleting user 
having information elements identifying said delete content primitive, a delete transaction, the 
deleting user, a deleting client used by said deleting user, said group, and content for deletion, 
and by 

a step of said server deleting said shared content. 

37. (Original) The presence information service management method of claim 22, further 
characterized by 
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a step of said server providing (552) a content information primitive to a notified user 
from a server having information elements identifying said content information primitive, a store 
transaction, and a header, by 

a step of said server receiving (562) a get content information primitive from said notified 
user having information elements identifying said get content primitive, a retrieval transaction, 
and said notified user, and by 

a step of said server providing (565) a receive content primitive from said server to said 
notified client having information elements identifying said receive content primitive, said 
retrieval transaction, said header, and having an information element containing shared content. 

38. (Original) The method of claim 34 for adding to said shared content at said server by a 
storing user, further characterized by a step of said server receiving (550) a store content 
primitive at said server having content in an information element thereof for said adding to said 
shared content along with or according to information elements identifying said store content 
primitive, a store transaction, the storing user and a header. 

39. (Original) The method of claim 37 for deleting from said shared content at said server by 
a deleting user, further characterized by a step of said server receiving (564) a delete content 
primitive from said deleting user at said server, said primitive having information elements 
identifying said delete content primitive, a delete transaction, the deleting user and content for 
deletion. 

40. (Original) The presence information service management method of claim 22, further 
characterized by an exception management method for use in exception handling of a transaction 
by a user or server in responding to a request by said server or said user, respectively, by 

a step of providing a status primitive in said responding to said request for indicating 
success or failure of said transaction as well as further information contained in information 
elements of said status primitive, and by 

a step of receiving said status primitive in said requesting server or said requesting user 
for recognizing said indication of success or failure. 
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41. (Original) The method of claim 40, wherein said information elements include a message 
identifier, a transaction identifier, and a status value indicative of said success or failure. 

42. (Original) A server for carrying out a presence information service management 
method for clients, characterized by 

means (625; 133p) for receiving presence authorization messages (37, 38, 64; 84) 
from users wherein said presence authorization messages are initiated by said users to authorize 
access to selected presence information of said users, by 

means (425) for receiving presence information update messages (31,35; 86) from 
updating users wherein said update messages are initiated by said updating users, by 

means (46s; 133i) for receiving presence information request messages from 
presence service requesting users including users requesting presence information to which a 
response is required and including subscribing users initially subscribing to presence information 
to which on-going responses including requested presence information are required, by 

means (133f) for determining if access to said requested presence information has been 
authorized and, if not, for requesting authorization (133n) from a requested user whose presence 
information has been requested, and by 

means (50s; 133k) for providing said requested presence information to which a response 
is expected to said requesting users requesting presence information to which a response is 
expected and for providing requested presence information on an on-going basis to said 
subscribing users subscribing to presence information to which on-going responses are required, 
particularly after receiving said presence information update messages from said updating users. 

43. (Original) The server of claim 42, characterized in that each of said presence 
information request messages comprises a primitive having various mandatory information 
elements including a message identifier, a transaction identifier, and an identification of a 
requested user. 

44. (Original) The server of claim 43, characterized in that said primitive has at least one 
optional information element comprising a list of presence values requested. 



21 



45. (Original) The server of claim 42, characterized in that said means for requesting 
authorization from a requested user provides an authorization message comprising a primitive 
having various mandatory information elements including a message identifier, an authorization 
request transaction identifier, a requesting user identifier and a list of presence values. 

46. (Original) The server of claim 42, characterized in that presence information is 
authorized by means of said authorization messages from authorizing users each comprising an 
authorization primitive having various mandatory information elements including a message 
identifier, an authorization request transaction identifier, a requesting user identifier, and a list of 
presence values. 

47. (Original) The server of claim 46, characterized in that said primitive has at least 
one optional information element comprising a group identifier if authorization is related to a 
group. 

48. (Original) The server of claim 42, characterized in that a buddy list user maintains one 
or more buddy lists on a server for sending messages to one or more recipient users separately or 
to a whole buddy list, wherein the recipient users are not necessarily aware of the buddy list and 
cannot refer to the buddy list with any replies they make, and said buddy list user maintaining 
one or more buddy lists on said server is able to access buddy list presence information. 

49. (Original) The server of claim 42, further characterized by 

means (258) for receiving join group primitives from member users joining a private user 
group, by 

means (266) for providing presence primitives indicative of presence information of 
member users of said private user group to each member user upon joining said private user 
group but not after departing, and by 

means (288) for providing group left primitives indicative of departed member users to 
remaining private user group member users upon receipt of leave group primitives indicative of 
said departing member users. 
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50. (Original) The server of claim 49, characterized in that member users are joined by said 
step of joining only if said join group message is preceded by providing an invitation to join 
primitive to said joining member user. 

5 1 . (Original) The server of claim 42, further characterized by 

means (450) for receiving a create group primitive from a member user creating a user 
group, said create group primitive having information elements indicative of identification of a 
client used by the user creating the user group, identification of the member user creating the 
user group, and a list of member users of the user group, by 

means (456) for reporting to the member users with a group information primitive 
indicative of establishment of the user group and selected group information, and by 

means (27b) for permitting member users of the user group to interchange message 
primitives. 

52. (Original) The server of claim 51, further characterized by 

means (458) for receiving a request for group information from a requesting member 
user, and by 

means (456) for reporting to the requesting member user with a group information 
primitive indicative of selected group information. 

53. (Original) The server of claim 51, further characterized by 

means (462) for receiving a request to modify said user group from a requesting member 
user, and by 

means (456) for reporting to the requesting member user with a group information 
primitive indicative of selected group information. 

54. (Original) The server of claim 51, further characterized by 

means (466) for receiving a request to delete said user group from a requesting member 
user, and by 
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means (456) for reporting to the member users with a status primitive indicative of 
disestablishment of said user group. 

55. (Original) The server of claim 42, further characterized by 

means (650) for receiving a store content primitive from a storing user and storing any 
content conveyed in a content information element of said content primitive along with or 
according to information elements identifying said store content primitive, a store transaction, a 
storing user, a storing client used by said storing user, a group, properties of said content, and a 
header of said content, by 

means (660) for providing a content information primitive to member users in said group 
having information elements identifying said content information primitive, said store 
transaction, and said header, by 

means (654) for receiving a get content information primitive from a retrieving user in said 
group having information elements identifying said get content primitive, a retrieval transaction, 
the retrieving user, a retrieving client used by said retrieving user, and said group, and by 

means (668) for providing a receive content primitive to said retrieving user having 
information elements identifying said receive content primitive, said retrieval transaction, said 
group, said content, said header of said content, and having an information element containing 
shared content for storing among said member users. 

56. (Original) The server of claim 49, further characterized by 

means (670) for receiving a delete content primitive from a deleting user having 
information elements identifying said delete content primitive, a delete transaction, the deleting 
user, a deleting client used by said deleting user, said group, and content for deletion, and by 

means (27b) for deleting said shared content. 

57. (Original) The server of claim 42, further characterized by 

means (660) for providing a content information primitive to a notified user from a server 
having information elements identifying said content information primitive, a store transaction, 
and a header, by 
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means (654) for receiving a get content information primitive from said notified user 
having information elements identifying said get content primitive, a retrieval transaction, and 
said notified user, and by 

means (668) for providing a receive content primitive from said server to said notified 
client having information elements identifying said receive content primitive, said retrieval 
transaction, said header, and having an information element containing shared content. 

58. (Original) The server of claim 57, further characterized by means (650) for receiving a 
store content primitive at said server having content in an information element thereof for said 
adding to said shared content along with or according to information elements identifying said 
store content primitive, a store transaction, the storing user and a header. 

59. (Original) The server of claim 57, further characterized by means (670) for receiving a 
delete content primitive from said deleting user at said server, said primitive having information 
elements identifying said delete content primitive, a delete transaction, the deleting user and 
content for deletion. 

60. (Original) The server of claim 42, further characterized by 

means (710; 730) for use in exception handling of a transaction by a user or server in 
responding to a request by said server or said user, respectively, by 

means (714; 734) for providing a status primitive in said responding to said request for 
indicating success or failure of said transaction as well as further information contained in 
information elements of said status primitive, and by 

means (720; 740) for receiving said status primitive in said requesting server or said 
requesting user for recognizing said indication of success or failure. 

61. (Original) The server of claim 60, wherein said information elements include a 
message identifier, a transaction identifier, and a status value indicative of said success or failure. 

62. (Previously Presented) A system for the management of presence information for use in a 
communication system comprising: 
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a client; and 

a server in the network, wherein the client and the server are able to exchange presence 
information having a data structure according to claim 1 . 
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IX. EVIDENCE APPENDIX (37 CFR § 41.37(cKl¥ixV) 
None. 
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X. RELATED PROCEEDINGS APPENDIX (37 CFR § 41.37(cKl¥x» 
None. 
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